10 research outputs found

    Reasoning About Foreign Function Interfaces: Blame and Nondeterministic Formal Semantics

    Get PDF
    Foreign function interfaces (FFIs) are commonly used as a way to mix programming languages. In such systems, a program written in a host language calls functions written in a guest language from within the same program. Perhaps the most popular language to interface with is C, due in no small part to its performance (often gained through unsafe operations), and programmers often write performance-critical code in C and call it from other languages. But while C is a very performant language, it is far from being memory-safe, and one might expect C to introduce unsoundness into host language systems. This host/guest language relationship echoes that of typed and untyped code in gradual type systems. In such systems, untyped values flowing into typed code must be cast at the boundary between typed and untyped code, and this introduces the possibility for runtime type errors in otherwise statically guaranteed code. Similarly, when a host language calls a function written in a guest language, this introduces any unsoundness in the guest language to the host language, and new errors become possible at runtime. And when an FFI is being used to call C functions, anything is possible. In this thesis, we explore the effects of C on languages using a C FFI. To demonstrate, we give a formalization of Poseidon Lua, an environment wherein Typed Lua code may call C functions, cast C values, and allocate C data. To showcase the interaction between Lua and C, we choose to formalize a core calculus for Lua, and do not model C per se; instead, we reason about C as if C calls were a black-box, remaining general with respect to C's semantics, while carefully quantifying the effects that C can have on Lua by leveraging the concept of blame from gradual typing. We present a nondeterministic operational semantics for Poseidon Lua, and use blame to assure that C is always at fault for runtime errors in Lua

    Reasoning About Foreign Function Interfaces Without Modelling the Foreign Language (Artifact)

    Get PDF
    There are two components to this artifact. First, a we provide a mechanization of the formalization in the paper, as well as mechanized proofs of the main results from the paper. Second, we provide a full implementation of Poseidon Lua, the language implemented in the paper. Instructions for all components of the artifact are included this document

    Reasoning About Foreign Function Interfaces Without Modelling the Foreign Language

    Get PDF
    Foreign function interfaces (FFIs) allow programs written in one language (called the host language) to call functions written in another language (called the guest language), and are widespread throughout modern programming languages, with C FFIs being the most prevalent. Unfortunately, reasoning about C FFIs can be very challenging, particularly when using traditional methods which necessitate a full model of the guest language in order to guarantee anything about the whole language. To address this, we propose a framework for defining whole language semantics of FFIs without needing to model the guest language, which makes reasoning about C FFIs feasible. We show that with such a semantics, one can guarantee some form of soundness of the overall language, as well as attribute errors in well-typed host language programs to the guest language. We also present an implementation of this scheme, Poseidon Lua, which shows a speedup over a traditional Lua C FFI

    The Effects of Computational Resources on Flaky Tests

    Full text link
    Flaky tests are tests that nondeterministically pass and fail in unchanged code. These tests can be detrimental to developers' productivity. Particularly when tests run in continuous integration environments, the tests may be competing for access to limited computational resources (CPUs, memory etc.), and we hypothesize that resource (in)availability may be a significant factor in the failure rate of flaky tests. We present the first assessment of the impact that computational resources have on flaky tests, including a total of 52 projects written in Java, JavaScript and Python, and 27 different resource configurations. Using a rigorous statistical methodology, we determine which tests are RAFT (Resource-Affected Flaky Tests). We find that 46.5% of the flaky tests in our dataset are RAFT, indicating that a substantial proportion of flaky-test failures can be avoided by adjusting the resources available when running tests. We report RAFTs and configurations to avoid them to developers, and received interest to either fix the RAFTs or to improve the specifications of the projects so that tests would be run only in configurations that are unlikely to encounter RAFT failures. Our results also have implications for researchers attempting to detect flaky tests, e.g., reducing the resources available when running tests is a cost-effective approach to detect more flaky failures.Comment: This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessibl

    The SPARC Toroidal Field Model Coil Program

    Full text link
    The SPARC Toroidal Field Model Coil (TFMC) Program was a three-year effort between 2018 and 2021 that developed novel Rare Earth Yttrium Barium Copper Oxide (REBCO) superconductor technologies and then successfully utilized these technologies to design, build, and test a first-in-class, high-field (~20 T), representative-scale (~3 m) superconducting toroidal field coil. With the principal objective of demonstrating mature, large-scale, REBCO magnets, the project was executed jointly by the MIT Plasma Science and Fusion Center (PSFC) and Commonwealth Fusion Systems (CFS). The TFMC achieved its programmatic goal of experimentally demonstrating a large-scale high-field REBCO magnet, achieving 20.1 T peak field-on-conductor with 40.5 kA of terminal current, 815 kN/m of Lorentz loading on the REBCO stacks, and almost 1 GPa of mechanical stress accommodated by the structural case. Fifteen internal demountable pancake-to-pancake joints operated in the 0.5 to 2.0 nOhm range at 20 K and in magnetic fields up to 12 T. The DC and AC electromagnetic performance of the magnet, predicted by new advances in high-fidelity computational models, was confirmed in two test campaigns while the massively parallel, single-pass, pressure-vessel style coolant scheme capable of large heat removal was validated. The REBCO current lead and feeder system was experimentally qualified up to 50 kA, and the crycooler based cryogenic system provided 600 W of cooling power at 20 K with mass flow rates up to 70 g/s at a maximum design pressure of 20 bar-a for the test campaigns. Finally, the feasibility of using passive, self-protection against a quench in a fusion-scale NI TF coil was experimentally assessed with an intentional open-circuit quench at 31.5 kA terminal current.Comment: 17 pages 9 figures, overview paper and the first of a six-part series of papers covering the TFMC Progra

    The SPARC Toroidal Field Model Coil Program

    Get PDF

    signatr: A Data-Driven Fuzzing Tool for R

    No full text
    International audienceThe fast-and-loose, permissive semantics of dynamic programming languages limit the power of static analyses. For that reason, soundness is often traded for precision through dynamic program analysis. Dynamic analysis is only as good as the available runnable code, and relying solely on test suites is fraught as they do not cover the full gamut of possible behaviors. Fuzzing is an approach for automatically exercising code, and could be used to obtain more runnable code. However, the shape of user-defined data in dynamic languages is difficult to intuit, limiting a fuzzer's reach. We propose a feedback-driven blackbox fuzzing approach which draws inputs from a database of values recorded from existing code. We implement this approach in a tool called signatr for the R language. We present the insights of its design and implementation, and assess signatr's ability to uncover new behaviors by fuzzing 4,829 R functions from 100 R packages, revealing 1,195,184 new signatures

    Token Swapping on Trees

    No full text
    The input to the token swapping problem is a graph with vertices v1,v2,…,vnv_1, v_2, \ldots, v_n, and nn tokens with labels 1,2,…,n1, 2, \ldots, n, one on each vertex. The goal is to get token ii to vertex viv_i for all i=1,…,ni= 1, \ldots, n using a minimum number of \emph{swaps}, where a swap exchanges the tokens on the endpoints of an edge. Token swapping on a tree, also known as "sorting with a transposition tree", is not known to be in P nor NP-complete. We present some partial results: 1. An optimum swap sequence may need to perform a swap on a leaf vertex that has the correct token (a "happy leaf"), disproving a conjecture of Vaughan. 2. Any algorithm that fixes happy leaves---as all known approximation algorithms for the problem do---has approximation factor at least 4/34/3. Furthermore, the two best-known 2-approximation algorithms have approximation factor exactly 2. 3. A generalized problem---weighted coloured token swapping---is NP-complete on trees, but solvable in polynomial time on paths and stars. In this version, tokens and vertices have colours, and colours have weights. The goal is to get every token to a vertex of the same colour, and the cost of a swap is the sum of the weights of the two tokens involved

    Fabaceae Lindl.

    No full text
    corecore